home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / doc / www_talk.arc / 000177_connolly@pixel.convex.com _Wed Jul 15 00:26:56 1992.msg < prev    next >
Internet Message Format  |  1992-11-30  |  3KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA02064; Wed, 15 Jul 92 00:26:56 MET DST
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA13260; Wed, 15 Jul 92 00:26:28 +0200
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA18318; Tue, 14 Jul 92 17:25:58 -0500
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA07409; Tue, 14 Jul 92 17:25:57 -0500
  10. Message-Id: <9207142225.AA07409@pixel.convex.com>
  11. To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
  12. Cc: www-talk@nxoc01.cern.ch
  13. Subject: Re: rethinking the HTML DTD. 
  14. In-Reply-To: Your message of "Wed, 15 Jul 92 00:03:56 +0700."
  15.              <9207142203.AA02008@ nxoc01.cern.ch > 
  16. Date: Tue, 14 Jul 92 17:25:56 CDT
  17. From: Dan Connolly <connolly@pixel.convex.com>
  18.  
  19.  
  20. Ok, so we really do want to use SGML. Good. I agree. I just
  21. wanted to hear from the WWW community.
  22.  
  23. >
  24. >You say HTML is not SGML.  It is true that the HTML generted by the NeXT editor
  25. >is not good. (example, lack of quotes around attributes which need them.)
  26. >Hwoever, the current parser wil parse real SGML. 
  27. >
  28. The biggest problem with HTML files is that they have only 1 of the 3
  29. basic parts of an SGML document: the SGML declaration, the prologue,
  30. and the instnace. HTML documents only have the instance. It's legal
  31. to omit the SGML declaration -- there's a default. But you've got
  32. to have a prologue, or you end up with a non-standard way of infering
  33. the prologue (for example, every WWW client infers the DTD described
  34. in "http://info.cern.ch/hypertext/WWW/MarkUp/Tags.html".)
  35.  
  36. So if we're commited to SGML, let's start putting something like
  37.  
  38. <!DOCTYPE HTML SYSTEM "http://info.cern.ch/hypertext/WWW/MarkUp/html.dtd">
  39.  
  40. at the front of every HTML file (we don't have to store it in the
  41. file -- servers that distribute HTML could generate it on the fly.)
  42. And let's put _some_ kind of DTD there.
  43.  
  44. >In the future, the web will inclued more complex DTDs, and dynamically
  45. >loaded DTDs, and people will want to use the same parser for it.
  46. >
  47. Interesting! There are plans to support more than one DTD!
  48. This makes SGML a clear winner.
  49.  
  50. >So I feel RTF would be a backward step. It is true that the current
  51. >W3 software is at a point level with RTF rather than general SGML.
  52. >But why tie ourselves to that point?
  53. >
  54.  
  55. I guess that's what I wanted to hear: that the goals of WWW and the
  56. features of SGML really _do_ have a lot in common, but the current
  57. implementation doesn't support many of them.
  58.  
  59. Just to make sure I've beat this horse to death: let's begin to
  60. formalize HTML and validate existing HTML documents before the
  61. distance between HTML and SGML gets too big.
  62.  
  63. Dan
  64.  
  65. p.s. I'm working on a DTD that reflects the structure of most existing
  66. word-processor documents: a sequence of paragraphs (maybe broken
  67. into flows, sections, or whatever). I'll have RTF and MIF translators
  68. for the DTD when it's ready. Maybe HTML2 can use some of the features --
  69. the low level character-set related features, anyway.
  70.  
  71.